A:

Here's my quick list of things to ask yourself when you get a crash. Most of them seem really obvious, but one of these questions solves pretty much every technical support query we get!

Go through the questions one by one and don't assume the answer to any of them - actually explore each question. Without fail, the most complicated crashes are usually reduced to one simple assumption that was never completely confirmed.

1) What call is crashing? Does it crash every time, or just once in a while?

2) If you cut that call into one of the Miles sample applications, does it still crash?

3) Is the problem data-dependent? Do other sound files work?

4) Don't overlook the obvious - what are the contents of the parameters being passed to the crashing function? Are they valid? Double-check them at run-time in the debugger.

5) Are you using the latest version of Miles? See the "What is the latest version of MSS?" FAQ for details.

6) Make sure that the header file, the DLLs and shared libraries, and all of the add-on files (the ASIs, FLTs, etc) are all the same version! Scan your drive for the Miles library files - make sure there are none on your drive except the very latest version.

7) Miles is used in a lot of games (about 700 per year). If you are getting a crash, try to imagine what is different about your application - are you doing anything you'd guess is unusual?

8) Try never freeing your sound memory buffers. You'll leak memory, but if you don't crash, then you are probably freeing a piece of memory before Miles is done with it. See the "When can I free the memory I gave to MSS?" FAQ for details.

9) Does it happen on a specific machine? On a specific OS? Does it only happen with a particular sound card? Do you have the latest sound card drivers for your sound card?

10) Does it only happen when a particular channel specification (MSS_MC_SPEC value) is passed to AIL_open_digital_driver?

11) Create and examine a Miles call log (see the call logging sections in the Overview sections of this document). Does anything appear unusual?

12) Build the Miles DLL in debug mode - can you tell what's happening from the crash location in the source code? See the "How can I rebuild the Miles source code?" FAQ for details.

13) Try simplifying the problem. Turn off everything unnecessary (DSP filters, 3D spatialization, reverb, etc.) - does it affect the crash?

14) Are you using callbacks? Try turning them off completely - does it still crash?

15) Finally, if you've been able to reproduce a crash in Miles, send us the example (keep it short and simple - the console applications in the \Examples directory are a good place to start) and we'll get it fixed for you. RAD can usually fix reproducable problems within days!